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SWMARY 


5fcis  paper  looks  at  the  many  problems  facing  the  manager  of  a 
materiel  acquisition  program  in  assuring  successful  and  timely  develop¬ 
ment,  test,  production  and  fielding  of  a  new  piece  of  equipment.  While 
it  does  not  offer  startling  new  concepts  in  shortening  the  acquisition 
process,  it  does  offer  suggestions  on  how  to  avoid  common  pitfalls  in 
program  management.  An  example  of  the  9th  Infantry  Division  High 
Technology  Light  Division  program  is  given  within  the  context  of  shor¬ 
tening  the  acquisition  cycle. 


\ 
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INTRODUCTION 


The  purpose  of  this  paper  is  to  look  at  the  way  the  Army  goes  about 
the  business  of  acquiring  new  equipment.  It  will  focus  primarily  on 
Army  programs,  but  it  will  encompass  the  broader  aspects  of  the  overall 
approach  used  by  the  Department  of  Defense.  I  will  draw  upon  the 
literature  associated  with  the  materiel  acquisition  process  and  my  own 
experience  working  with  several  Army  programs  and  one  Navy  program.  I 
hope  to  be  able  to  point  out  some  of  the  problems  in  running  acquisition 
programs,  and  make  some  recommendations  on  how  to  improve  and  accelerate 
the  entire  process. 

The  design,  testing,  production  and  fielding  of  new  equipment  has 
always  received  a  lot  of  attention.  Most  of  this  attention  centers  on 
the  high  cost  of  doing  business,  but  much  criticism  is  directed  toward 
the  actual  hardware  performance  and  the  many  delays  in  producing  it. 
There  is  a  perception  from  the  field  that  the  overall  process  of 
upgrading  Army  inventories  with  new  and  modem  equipment  takes  too  long. 
The  favorite  example  cited  for  a  program  being  too  long  in  delivering 
results  is  TACFIRE,  a  system  that  was  highly  touted  over  twenty  years 
ago  when  most  of  the  current  group  of  senior  officers  were  first  coming 
on  active  duty.  TACFIRE  is  just  now  in  the  early  fielding  process;  the 
concept  and  design  of  TACFIRE  has  gone  through  many  generations;  it  is 
not  the  intent  of  this  paper  to  analyze  the  TACFIRE  program,  but, 
rather,  to  point  out  that  it  is  a  bit  of  a  millstone  for  those  of  us  in 


the  materiel  acquisition  business  to  carry  about! 

Under  the  Reagan  administration  policy  of  fiscal  reductions  in 
nearly  every  federal  program  except  defense,  which  has  received  dramatic 
increases,  attention  is  being  paid  to  the  high  cost  of  doing  business. 

The  Army  has  been  receiving  the  brunt  of  congressional  criticism  for  its 
high  dollar  overruns  on  such  programs  as  the  Abrams  tank,  the  Bradley 
fighting  vehicles  and  the  new  attack  helicopter.  With  the  FY  83  budget 
proposal  under  close  scrutiny,  Army  program  managers  are  feeling  the 
heat  from  the  critics'  fires.  To  put  program  costs  in  perspective, 
about  $23  billion  are  proposed  for  spending  on  Research  and  Development 
(R&D)  and  procurement  in  the  Army's  share  of  the  FY  83  budget  (1).  These 
dollars,  directed  primarily  at  acquisition  of  new  equipment,  represent 
about  39%  of  the  total  Army  budget;  however,  when  these  dollars  are  put 
in  the  context  of  total  proposed  federal  spending  for  FY  83,  they  repre¬ 
sent  only  3%  of  the  total  national  budget.  The  entire  DOD  R&D  and 
procurement  programs  represent  about  15%  of  the  total  budget.  Although 
the  proportion  of  the  total  budget  seems  rather  small,  one  should  not 
become  too  complacent  about  the  critics  of  defense  programs. 

The  fact  that  there  is  an  image  of  mismanagement  associated  with 
cost  overruns  and  program  delays  is  the  reason  that  they  become  such 
easy  targets  for  criticism.  There  is  nothing  new  in  the  materiel  acqui¬ 
sition  program  being  under  attack.  The  Hoover  Commission  in  the  1950's 
paid  a  lot  of  attention  to  the  problem  of  high  costs  (2).  The  Govern¬ 
ment  Accounting  Office  (GflO)  has  been  looking  at  the  way  DCD  does  busi¬ 
ness  for  many  years,  making  many  recommedations  in  the  process. 

Within  the  Army,  one  program  in  particular  has  received  a  lot  of 
attention,  the  High  Technology  Test  Bed  Project  of  the  9th  Infantry 
Division  at  Fort  Lewis,  Washington.  The  mission  of  the  9th  Division,  in 


addition  to  its  normal  FORSOOM  missions,  was  given  to  it  by  the  Chief  of 

Staff  of  the  Army  in  October,  1981  0): 

Commander,  9th  Infantry  Division,  is  charged  with  developing 
revolutionary  approaches  in  tactics  and  equipment  that  can 
evolve  into  a  new  kind  of  division;  field  a  High  Technology 
Light  Division  by  1985. 

If  ever  a  mission  was  designed  to  stress  the  materiel  acquisition 
system,  the  above  mission  must  be  a  classic  example.  Within  this  paper 
the  HTTB  project  will  be  given  a  closer  look  at  how  it  is  attempting  to 
cut  through  the  normal  inertia  associated  with  the  acquisition  process. 

With  Army  programs  being  criticized  from  without  for  their  high 
cost,  and  from  within  for  their  apparent  delays  in  producing  tangible 
results,  i.e.,  putting  new  equipment  into  the  hands  of  our  troops  in  a 
short  period  of  time,  it  is  worthwhile  looking  into  the  entire  materiel 
acquisition  process  in  some  detail  to  see  where  the  problems  jure  and 
what  can  be  done  about  them.  During  the  course  of  this  investigation 
many  of  the  new  DOD  initiatives  (the  so  called  "Carlucci  Initiatives") 
to  improve  and  streamline  the  acquisition  process  will  also  be  looked 
at. 
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CHARACTERIZE*;  THE  ACQUISITION  PROCESS 


In  very  simple  terms  the  materiel  acquisition  process  is  a  system 
wherein  a  need  for  a  new  piece  of  equipment  is  identified;  something  is 
found  or  designed  to  meet  this  need;  the  item  is  purchased  or  produced, 
and  then  fielded;  the  item  is  used  until  it  is  phased  out  by  the 
fielding  of  a  newer  or  better  item.  A  more  official  terminology  would 
describe  these  various  phases  in  the  life  cycle  of  a  system  as  Concept 
Exploration,  Demonstration  and  Validation,  Full-Scale  Development, 
Production  and  Deployment.  The  various  guides,  directives  and  regula¬ 
tions  used  to  describe  this  process  are  both  legion  and  seem  to  be 
following  an  exponential  growth  curve.  DOD  has  discovered  that  in  just 
ten  years  (1971-1981)  the  number  of  directives  and  instructions  related 
to  the  acquisition  process  has  grown  from  15  to  114  (4).  The  challenge 
to  the  program  manager  under  fire  from  this  explosion  of  written  guid¬ 
ance  is  not  how  to  do  his  job,  but  how  to  feel  his  way  through  a  laby¬ 
rinth  of  regulations  without  violating  any  rules.  (Carlucci  Initiative 
14  has  recognized  this  problem  and  DOD  has  been  directed  to  reduce  the 
number  of  directives.) 

The  interesting  thing  about  the  phases  of  the  acquisition  process 
is  not  how  to  transit  successfully  through  them,  but  the  psychology  that 
is  associated  with  how  a  project  is  viewed  depending  on  what  stage  in 
the  process  it  is.  The  psychology  of  the  process  changes  with  time.  I 
would  summarize  it  as  four  general  questions,  each  of  which  is  roughly 
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associated  with  the  four  formal  phases  of  the  acquisition  process: 

1.  Will  it  work? 

2.  When  can  I  have  it? 

3.  What  will  it  cost? 

4.  Can  we  take  care  of  it? 

Figure  1  shows  the  approximate  timing  of  these  four  questions  in 
relation  to  the  phases  of  an  acquisition  program. 

What  these  four  questions  tend  to  do  is  to  prioritize  effort 
throughout  the  life  of  a  development  program.  They  tend  to  narrow  the 
field  of  view  to  what  is  of  greatest  interest  at  the  moment,  thus 
jeopardizing  the  success  of  the  program  by  emphasizing  a  few  aspects  of 
it  at  the  expense  of  others.  To  better  illustrate  what  I  mean,  I  will 
attempt  to  typify  what  these  four  questions  concentrate  on. 
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FIGURE  1 

THE  PSYCHOLOGY  OF  THE  ACQUISITION  PROCESS  AS  SEEN  IN 
RELATION  TO  THE  POUR  PHASES  OF  A  PROGRAM 
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The  natural  fascination  with  new  ideas  and  exotic  hardware  always 
receives  the  most  attention  at  the  beginning  of  a  program.  There  is 
normal  preoccupation  with  the  hardware  solution  to  a  problem.  Experts 
abound  at  this  stage  in  a  program.  Ask  fifty  colonels  of  infantry  what 
an  infantry  fighting  vehicle  should  look  like  and  you  will  likely 
receive  fifty  very  strong  opinions.  The  technical  challenge  reigns 
supreme  at  this  point,  e.g.,  can  we  really  build  a  main  battle  tank  that 
will  travel  50  mph  across  rough  terrain?  Is  there  an  air  superiority 
fighter  that  will  go  mach  3,  have  a  2,000  nautical  mile  combat  radius, 
and  be  totally  survivable?  Is  there  a  better  handgun  than  the  .45 
caliber  browning  automatic  (that  will  hit  the  target  even  when  I  jerk  the 
trigger  with  my  eyes  closed?)  and  so  forth.  The  psychology  of  the  “will 
it  work?"  phase  can  best  be  seen  in  action  at  the  annual  AUSA  convention 
in  Washington,  DC  Go  there  and  you  will  see  that  the  exhibits 
receiving  the  most  attention  -  other  than  those  with  the  prettiest  girls 
or  most  novel  trinkets  being  given  away  -  are  those  that  have  actual 
hardware  to  climb  on,  lift,  sight  along,  etc. 

This  overwhelming  interest  in  the  operational  aspects  of  new 
hardware  is  to  be  expected  and  is  in  no  way  abnormal;  however,  the 
really  pressing  questions  that  will  be  asked  in  later  phases  of  the 
program  need  to  be  looked  at  with  much  more  emphasis  at  the  front  end  of 
the  acquisition  cycle.  If  this  is  not  accomplished  with  a  certain 
amount  of  astuteness,  the  services  are  much  more  likely  to  be  embar¬ 
rassed  by  cost  overruns,  schedule  delays  and  fielding  problems  that  may 
appear  after  the  question  of,  "will  it  work?"  has  been  answered. 


Once  a  design  has  been  successful  in  meeting  a  stated  need,  there 
is  a  perfectly  normal  shifting  of  emphasis  and  interest  to  the  speed 
with  which  the  new  piece  of  hardware  can  be  put  in  the  hands  of  the 
troops.  It  is  at  about  this  point  in  the  program  that  birth  is  given  to 
that  most  alluring  of  all  milestones,  the  Initial  Operational  Capability 
(IOC).  IOC  becomes  very  critical  if  the  enemy  threat  has  increased  in 
sophistication  and  magnitude,  and  a  new  counter  to  the  threat  is  badly 
needed.  In  terms  of  the  formal  acquisition  process,  concepts  have  been 
explored  with  promising  results  and  the  demonstration  and  validation  of 
the  experimental  designs  begin  to  take  place.  These  activities  require 
a  significant  increase  in  funds  as  actual  hardware  is  being  built, 
usually  by  hand  and  very  expensively.  Increased  funding  results  in 
increased  visibility  in  the  budget  process  and,  consequently,  in  greater 
interest  on  the  part  of  Congress.  As  budget  requests  are  made  the 
promises  of  hardware  performance,  cost  control,  and  guaranteed  schedules 
begin  to  show  up  in  program  descriptions.  The  IOC  takes  on  an  almost 
mystic  quality  as  program  managers  and  legislative  liaison  officers 
attempt  to  convince  the  members  of  Congress  and  their  eager,  sharp-eyed 
staffers  that  here  is  a  new  system  that  is  urgently  needed,  absolutely 
affordable,  and  imminently  deliverable.  As  funding  becomes  available 
and  program  successes  start  to  accumulate,  there  is  great  pressure  to 
even  accelerate  the  schedule  to  deliver  earlier,  avoiding  costly  infla¬ 
tion  that  may  hit  the  program  if  it  stretches  out  too  long. 

At  this  point,  energy  is  focused  on  the  timeliness  of  the  program, 
since  the  "will  it  work?"  question  has  already  been  answered  in  the 
affirmative.  Once  again,  the  questions  that  need  to  be  asked  about 
affordability,  supportability,  etc.,  are  thought  of  but  they  just  don't 
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have  the  sane  urgency  as  the  question  of  tining. 

What  Will  It  Cost? 

Up  to  this  point  in  a  typical  program,  cost  has  been  a  relatively 
unimportant  matter.  Cost  levels  through  early  R&D  have  been  low,  and, 
in  proportion  to  total  life  cycle  costs,  only  a  small  fraction  of  the 
total  projected  costs  have  actually  been  spent.  In  a  recent 
presentation  to  an  Army  War  College  advanced  course,  Brigadier  General 
Winfield  S.  Scott  (USA,  Retired),  pointed  this  out  graphically  (see 
Figure  2)  (5) . 
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TYPICAL  DEFENSE  SYSTEM  COST 
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As  can  be  seen  from  the  illustration,  a  program  which  has  answered  the 
first  two  questions  of  "will  it  work?"  and  "when  can  I  have  it?"  has 
come  to  that  point  in  the  program  where  a  full  scale  development  deci¬ 
sion  is  being  reached,  or  is  about  to  be  reached.  Costs  will  begin  to 
increase  significantly  as  more  engineering  hardware  is  being  built  and 
production  planning  becomes  more  intense.  The  schedule  and  IOC  are 
still  driving  the  program,  but  costs  are  becoming  more  important  as  they 
begin  to  show  up  in  future  projections  and  Five  Year  Programs.  The 
contractor,  because  he  is  still  in  the  planning  stage  for  production, 
does  not  have  a  highly  accurate  cost  estimate  for  production  quantities. 
He  is  unable  to  foresee  design  perturbations  that  may  have  an  impact  on 
production  costs;  there  may  be  a  competitive  development  program  going 
on,  in  which  case  there  is  a  natural  pressure  to  keep  cost  estimates 
optimistically  low.  The  government  does  not  do  its  part  in  discouraging 
optimistic  cost  estimating,  for  the  official  inflation  indices  that  must 
be  used  to  project  costs  into  the  future  are  always  much  lower  than 
actual  experience  indicates  they  should  be. 

A  key  point  about  asking  the  "what  will  it  cost?"  question  is  that 
it  has  come  much  too  late  in  the  program.  Because  a  project  has  been 
initiated  to  meet  an  approved  need,  i.e.,  it  has  passed  the  Milestone  0 
decision  point,  and  because  a  concept  has  been  demonstrated  and  has 
proven  to  be  valid,  DCD  has  made  a  firm  commitment  to  buy  the  entire 
program.  In  other  words,  a  life  cycle  determination  has  already  been 
made.  Again,  calling  on  Brigadier  General  Scott's  expertise  in  this 
area  (€),  Figure  3  shows  how  cost  commitments  are  made.  Comparing  this 
to  Figure  2,  we  can  see,  in  the  hypothetical  program  being  depicted, 
that  even  though  only  15%  of  the  life  cycle  program  has  actually  been 
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life  crcte  costs- 
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spent  at  the  D6ARC  III  decision  point,  virtually  the  entire  life  cycle 
cost  has  been  committed. 


Granted,  a  program  can  always  be  terminated,  and  some  are,  but  for  most 
programs,  once  they  have  successfully  weathered  a  few  years  of  chal¬ 
lenges  from  the  budget  process,  chances  are  they  will  proceed  into  the 
production  phase. 

Can  We  Take  Care  Of  It? 

Having  fought  the  battles  of  performance,  schedule  and  cost,  a  new 
system  becomes  a  reality  as  it  enters  into  production  and  hardware 
begins  to  roll  out  the  door.  The  entire  process  of  planning  for  the  day 
when  the  first  troop  unit  receives  the  new  piece  of  equipment  has  been 
going  on  in  parallel  with  the  development  program,  but  these  logistics 
planners  have  been  the  "boys  in  the  back  room"  during  the  more  glamorous 
phases  of  the  program.  The  Army  has  done  much  to  codify  and  make 
systematic  the  whole  Integrated  Logistic  Support  (ILS)  process,  but 
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support  packages  just  don't  receive  high  priority  interest  when  the  more 
urgent  matters  of  performance,  schedule  and  cost  are  in  their  prime. 

The  main  program,  i.e.,  the  program  of  the  major  piece  of  equipment, 
drives  the  early  decision  points  in  the  program.  Although  ILS  is  impor¬ 
tant,  problems  with  test  equipment  or  technical  manuals  are  not  going  to 
influence  the  program  until  that  time  in  the  acquisition  cycle  when 
production,  type  classification  and  fielding  decisions  are  being  made. 

It  is  only  when  troop  units  are  on  the  receiving  end  of  new  equipment 
that  organizational  structure,  personnel  fill  and  training,  etc.,  become 
the  dominant  factors  in  the  program.  The  question  of  "can  we  take  care 
of  it?"  which  is  the  last  of  the  "Big  Four"  questions  to  be  asked,  is 
finally  at  the  focus  of  attention.  This  question  has  probably  been 
asked  all  during  program  development  phases,  but  only  in  a  small  voice. 
As  fielding  occurs  the  voice  becomes  large  and  loud,  especially  if  a 
million  dollar  end  item  sits  idle  for  the  lack  of  a  $100  tool  or  spare 
part. 
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V 


BOW  PROGRAMS  GET  INTO  TROUBLE 


Baving  looked  at  the  psychological  environment  in  which  a  program 

operates  during  its  life  cycle,  I  would  like  to  describe  how  programs 

get  into  trouble,  and  why  it  is  that  the  acquisition  process,  in 

general,  is  so  greatly  criticized.  First,  let's  take  a  lode  at  typical 

"complaints"  about  the  acquisition  cycle  (7) : 

Coiwress/GAO  View.  Services  try  to  do  too  much  at  one  time  - 
always  looking  for  quantum  jumps  in  capability  which  cause 
excessive  cost  ....  Early  cost,  schedule,  and  performance 
estimates  are  consistently  overly  optimistic  and  highly 
unrealistic  ... 

OSD  View.  Too  many  systems  competing  for  scarce 
resources  ....  Inadequate  cost/performance/quantity/schedule 
trade-offs  during  conceptual  design  .  .  .  Lack  of  discipline  of 
system  technical  requirements  (gold-plating)  .  .  .  acquisition 
cycle  too  long. 

Service  View.  OSD  milestone  review  process  generates  excess 
amount  of  paperwork  ....  Excessive  micromanagement  of 
program  technical  issues  by  OSD  and  Congress. 

Program  Manager  View.  Too  many  reviews  by  too  many  layers  in 
both  OSD  and  service  ....  Too  many  regulations  and  reports 
..  .  .  Costs  required  too  far  in  advance  of  expenditure  dates. 

Industry  View.  Instability  is  caused  by  starts,  stops, 
stretch-outs,  redirections,  and  inordinately  long  decision 
times  ....  Over  emphasis  on  price  competition  leads  to  lack 
of  cost  realism  .  .  .  overmanagement  by  the  government  .... 
Adversarial  attitudes  are  held  by  many  government  personnel. 

As  can  be  seen  from  the  opinions  above,  even  though  they  are  from 
diverse  sources,  they  all  seem  to  point  to  a  complex,  overly  bureau¬ 
cratic  system  that  is  impossible  to  perform  under  and  impossible  to 
manage.  It  is  my  experience  that  programs  do  get  managed,  contractors 
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do  build  equipment,  and  new  systems  do  get  fielded,  so  the  acquisition 
process  is  far  from  being  an  impossible  system  to  work  under.  It  does 
take  extraordinary  efforts  on  the  part  of  the  program/project  management 
team,  good  luck  on  test  programs,  and  a  highly  cooperative  government- 
industry  relationship  to  successfully  work  a  program  through  the  laby¬ 
rinthine  acquisition  system.  Programs  get  into  trouble  for  a  variety  of 
reasons.  The  basic  acquisition  system  is  at  odds  with  the  source  of  its 
impetus  -  money.  Figure  4  illustrates  how  two  massive  systems  are 
always  in  collision.  The  acquisition  cycle  is  almost  totally  event- 
oriented.  A  program  must  successfully  pass  through  a  series  of  decision 
barriers  that  are  almost  totally  dependent  on  successful  hardware  test 
results.  A  sequential  series  of  events  marks  a  program's  progress  as  it 
proceeds  through  design-test-decision  point  from  one  phase  of  a  program 


PPBS  CYCLE  - 
Time  Oriented 
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to  the  next.  In  contrast  to  this  chain  of  events  is  the  process  by 
which  a  program  is  fueled,  namely,  the  budgetary  process.  Hie  Planning, 
Programming  and  Budgeting  System  -  PFBS,  as  it  is  commonly  known  -  is 
one  that  is  tied  strictly  to  the  calendar.  It  is  keyed  directly  to  the 
budget  cycle  which  follows  virtually  the  same  pattern  every  year.  Not 
only  is  the  PFBS  relentless  in  its  course  throughout  the  fiscal  year, 
but  it  exposes  major  programs,  i.e.,  programs  too  expensive  to  hide 
within  a  general  funding  category,  to  close  and  detailed  scrutiny  by 
Congress.  Mr.  Norman  Augustine  points  out  in  one  of  his  books  (8)  that 
a  program  must  go  through  no  fewer  than  eighteen  reviews  each  year. 

These  are  reviews  by  different  committees  in  the  House  and  Senate  that 
have  a  part  in  the  overall  author ization  and  appropriation  process.  It 
is  rare  that  program  milestones  occur  at  points  in  time  to  conveniently 
justify  PFBS  requests  for  funds.  The  fundamental  clash  between  the  PFBS 
and  the  acquisition  system  is  the  first  cause  of  program  turbulence. 
Fluctuating  levels  of  funding  can  only  result  in  fluctuating  levels  of 
effort  on  the  part  of  the  contractor.  These  are  the  "starts,  stops, 
stretch-outs,  and  redirections"  that  are  mentioned  above  in  the  industry 
view  of  the  acquisition  system. 

Many  programs  survive  this  funding  challenge  every  year,  but  many 
other  programs  suffer  because  they  fail  to  deliver  on  promises  made  the 
previous  year.  The  answers  to  the  "Big  Four"  questions  can  begin  to 
haunt  a  program  if  there  are  too  many  unfulfilled  promises  on  hardware 
performance,  program  schedule,  cost  and  supportability  issues.  As  I 
will  develop  later  in  this  paper,  I  feel  that  the  timing  and  sufficiency 
of  money  is  the  basic  determinant  of  program  success;  hence,  the  PFBS 
treatment  of  programs  is  probably  more  important  that  the  mechanics  of 
the  acquisition  process,  per  se. 
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Taking  a  closer  look  at  the  acquisition  process,  it  becomes 
apparent  that  there  are  three  key  players  which  I  will  call  the  program 
(or  project)  manager,  the  contractor,  and  the  "system."  The  "system"  is 
a  nebulous,  ever-changing  conglomeration  which  includes  Congress,  COD, 
the  Service  Secretariat  and  Staff,  the  Major  Army  Commands  (MAOOMs)  and 
an  amorphous  entity  known  as  *The  User."  These  three  elements,  or 
players,  must  operate  within  the  confines  of  numerous  regulations;  each 
element  is  capable  of  making  the  program  go  forward,  languish  or  self- 
destruct.  Programs  most  often  will  get  into  trouble  when  the  program 
manager  and  contractor  run  afoul  of  the  "system,"  don't  understand  it, 
or  fail  to  "play"  it  properly  as  a  program  goes  through  its  various 
phases  and  hurdles  its  decision  points. 

Early  in  a  program,  the  most  difficult  thing  to  settle  on  is  the 
requirement.  A  requirement  has  many  forms  and,  over  the  years,  the 
document  describing  the  requirement  has  had  different  names.  What  was 
called  the  Mission  Element  Need  Statement  will  now  be  known  as  the 
Justification  of  Major  Systems  New  Starts  (JMSNS).  Under  the  Carlucci 
initiatives  (9)  the  JMSNS  will  be  synchronized  with  the  Program  Objective 
Memorandum  (POM)  each  year.  The  birth  of  the  acquisition  process  will 
thus  be  put  into  the  PH3S,  i.e.,  the  POM  input  to  the  PPBS,  when 
approved,  will  carry  with  that  approval  all  of  the  JMSNS' s  that  happen 
to  be  in  the  POM.  In  simpler  terms,  when  a  POM  is  approved,  approval  of 
its  components,  which  include  all  the  JMSNS*s  for  the  fiscal  year  in 
question,  is  automatic.  This  is  probably  the  only  time  that  the  PPBS 
and  Acquisition  Cycle  are  together!  Once  the  JMSNS  is  approved  the 
program  manager  has  in  hand  his  requirement  to  launch  a  new  program. 
Ideally,  this  requirement  is  so  well  written,  so  current  with  the  state 
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of  the  art,  and  so  precise,  that  the  rest  of  the  acquisition  process 
falls  easily  into  place.  Unfortunately,  the  requirement  is  often  a 
vague  attempt  to  describe  something  that  has  yet  to  be  proven.  More 
often,  a  requirement  and  its  related  design  concepts  interact  in  such  a 
way  that  they  are  not  sequential  activities  within  a  program.  Require¬ 
ment  definition  and  R&D  are  often  collateral  activities.  As  hardware 
designs  are  subjected  to  management  reviews,  congressional  scrutiny,  and 
a  constantly  changing  array  of  personnel  representing  "The  User,"  the 
requirement  has  a  way  of  becoming  a  fleeting  concept,  always  evolving 
into  something  a  little  different  from  the  original  idea  expressed  in 
the  JMSNSL  All  three  elements  (program  manager,  contractor,  and  the 
"system")  have  a  hand  in  changing  the  requirement.  The  manager  may  want 
to  change  things  to  meet  schedule  and  cost  problems;  the  contractor  may 
want  to  change  things  because  he  just  can't  meet  every  part  of  a 
requirement,  e.g.,  a  weight  limitation  may  limit  required  armor  protec¬ 
tion;  the  "system"  will  change  requirements  because  there  is  a  revised 
threat,  or  a  new  administration,  or  new  people  in  key  staff  and  leader¬ 
ship  positions.  The  challenge  of  stabilizing  the  requirement  is  the 
first  one  that  must  be  met  by  a  program  if  it  is  going  to  operate  with 
minimal,  difficulties  within  the  acquisition  process.  There  is  no  simple 
way  to  meet  this  challenge  of  the  "changing  requirement,"  but,  in  the 
next  section,  I  will  make  suggestions  on  how  some  of  the  turbulence  can 
be  reduced. 

Another  source  of  delay  is  the  failure  to  recognize  the  admini¬ 
strative  lead  time  associated  with  various  key  events  in  a  program 
schedule.  This  will  result  in  severe  delay  for  both  the  contractor  and 
the  program  manager  if  they  are  not  recognized  early  enough  to  allow  for 
sound  planing  of  activities.  I  will  look  first  at  the  contractor's 
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point  of  view,  and  some  of  the  problems  he  faces  in  traveling  through 
his  network  of  contractual  milestones.  To  illustrate  an  example  of 
this,  Figure  5  shows  a  hypothetical,  but  not  unrealistic,  period  in  a 
program’s  development  cycle.  A  typical  project  will  require  the 
contractor  to  design  and  build  hardware  for  testing.  The  contractor 
would  want  to  do  some  of  his  own  besting  on  the  design  to  assure  himself 
that  the  design  concepts  will  work.  Following  the  contractor  tests,  the 
government  would  normally  test.  For  the  Army,  this  would  either  be 
Development  Testing  (nr)  conducted  by  the  Test  and  Evaluation  Command 
(TEOOM) ,  or  an  Operational  test  (OT)  conducted  by  the  Operational  Test 


FIGURE  5 

A  SEGMENT  OF  A  PROGRAM  SCHEDULE 
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and  Evaluation  Activity  (OTEA),  or,  perhaps,  a  combined  DT/OT.  A  pro¬ 
gram  schedule  would  normally  show  these  activities  culminating  in  a 
simple  tick  mark  on  the  schedule  representing  a  major  decision  mile¬ 
stone,  e.g.,  ASARC  II.  Iftere  are  two  problems  with  this  type  of 
scheduling:  one  has  to  do  with  contractor  workloading,  and  the  other 
has  to  do  with  trying  to  compress  several  months  of  activities  into  a 
single  point  on  a  program  schedule.  I'll  call  this  latter  problem  the 
"tick  mark  syndrome,"  which  I  will  discuss  later.  First,  let's  look  at 
the  contractor's  problem. 

During  a  development  contract  the  contractor  will  assign  design 
engineers,  technicians,  etc.,  to  a  program  in  numbers  sufficient  to 
accomplish  the  required  tasks  on  time.  Chances  are  he  will  be  working 
on  a  cost  reimbursable  type  of  contract,  so  he  has  no  strong  incentive 
to  keep  his  work  force  lean.  Since  the  contractor  is  in  an  R&D  stage, 
the  same  engineers  and  technicians  involved  in  the  design  would  probably 
work  very  closely  with  the  actual  fabrication  of  the  item,  and  would 
then  work  with  the  test  programs.  This  is  normal  activity  for  a  devel¬ 
opment  effort,  and  the  contractor  has  no  real  problem  assigning  person¬ 
nel  to  the  project.  As  the  government  testing  begins,  however,  con¬ 
tractor  manhours  should  decrease,  because  there  isn't  as  much  contractor 
support  required.  The  question  now  facing  the  contractor  is  one  of 
personnel  placement.  What  does  he  do  with  his  projert  team  while  he  is 
waiting  on  a  government  decision  to  proceed?  A  large  contractor  with 
many  programs  has  some  degree  of  flexibility  in  assigning  his  personnel 
to  other  contracts  he  may  have  in  progress,  or,  to  a  limited  extent,  may 
be  able  to  place  a  few  of  his  personnel  on  overhead.  Sinc%  overhead 
rates  are  closely  audited  by  the  government,  there  is  a  practical  limit, 
as  well  as  a  legal  one,  as  to  the  number  of  personnel  that  can  be 
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assigned  overhead  tasks.  The  government  makes  a  mistake  if  it  assumes 
that  a  contractor  can  cope  with  large  fluctuations  in  manpower  require¬ 
ments  without  causing  future  problems  in  the  program.  In  severe  delays 
where  the  contractor  has  to  wait  several  months  for  the  next  phase  of 
the  program  to  move  ahead  with  new  funds  and  a  new  contract,  he  may  be 
faced  with  having  to  lay  off  some  of  his  program  team  -  he  simply  has 
run  out  of  options.  It  is  true  that  the  government  can  take  a  very 
narrow  view  of  this  problem,  i.e,  the  contractor  is  in  the  business  to 
take  risks,  and  the  government  certainly  has  no  obligation  to  keep  a 
contractor's  work  force  employed  at  a  certain  level.  On  the  other  hand, 
the  government  program  manager  should  not  expect  a  contractor  to  start 
right  up  with  the  next  phase  of  the  program  without  delays.  The  con¬ 
tractor  will  have  to  build  up  his  team  again,  or  even  train  new  person¬ 
nel  if  some  of  his  original  beam  has  found  employment  elsewhere.  There 
are  ways  to  avoid  this  problem  which  I  will  outline  in  the  next  section 
of  the  paper. 

A  more  serious  aspect  of  the  potential  delays  in  a  program  are 
those  caused  by  poor  management  on  the  part  of  the  program  manager  and 
the  "system."  Again,  referring  to  Figure  5,  it  can  be  seen  that  a  major 
decision  point  is  almost  totally  dependent  on  a  program  event;  in  the 
case  illustrated,  the  event  is  a  test.  A  test,  with  luck,  cm  go  fairly 
well,  but  the  documentation  associated  with  the  test  can  take  some  time 
to  put  together.  If  a  program  schedule  fails  to  include  sufficient  time 
for  a  test  report  to  be  written,  coordinated  and  published,  not  only  is 
the  decision  milestone  held  up,  but  the  contractor's  work  load  problem 
is  exacerbated  even  more  as  he  waits  for  the  next  phase  of  the  program 
bo  get  underway.  It  is  very  easy  for  a  program  milestone  to  change  from 
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a  single  point  in  time  to  a  stretched  out  segment  in  the  program 
schedule.  An  event  thought  of  as  a  tick  mark  is  now  a  bar  on  the 
graphical  representation  of  the  schedule.  This  "tick  mark  syndrome,"  as 
I  called  it  earlier,  can  be  particularly  active  where  program  phase 
changes  revolve  around  some  contractual  procurement  action.  Figure  6 
shows  another  example  where  a  tick  mark,  i.e.,  major  decision  point,  is 
dependent  on  many  interrelated  activities.  Perhaps  one  of  the  more 
difficult  milestones  to  get  through  is  selecting  a  single  contractor  to 
proceed  with  a  program  that  has  involved  two  or  more  competing  contrac¬ 


tors  in  the  development  phase.  The  competing  contractors  have  submitted 
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rival  designs  to  a  "shoot  out"  or  "fly  off"  of  some  sort  where  both 
designs  have  been  subjected  to  the  sane  test.  Along  with  test  results 
the  contractors  would  normally  be  required  to  submit  detailed  proposals 
for  the  next  phase  of  the  program.  In  the  case  illustrated,  not  only  is 
the  program  vulnerable  to  test  report  delays,  as  shown  in  Figure  5,  but 
the  entire  source  selection  process  can  take  months  to  complete.  If  a 
program  manager  has  been  carrying  this  part  of  the  program  as  a  tick 
mark  milestone,  he  will  very  likely  be  dismayed  when  he  realizes  all  the 
lengthy  processes  that  must  occur,  usually  in  sequence,  before  he  can 
move  on  into  the  next  phase  of  the  program.  As  Figure  6  shows,  source 
selection  involves  the  writing  of  a  plan  (that  must  go  through  its  own 
approval  cycle),  the  evaluation  of  test  results  and  proposals  by  a 
large,  unbiased  team  -  the  source  selection  team  -  the  selection  of  a 
winner  (also  required  to  be  approved,  and  also  subject  to  protest  action 
chi  the  part  of  the  losing  contractor)  and  the  negotiation  and  award  of 
the  next  contract  to  the  winner.  All  these  activities  are  complex  and 
take  time.  The  entire  source  selection  process  can  take  as  long  as  six 
to  nine  months.  Much  of  this  time  can  be  decreased  through  careful 
planning,  but  all  sorts  of  problems  can  be  avoided  if  the  program  schedule 
is  well  thought  out  and  recognizes  that  many  activities  cannot  be  por¬ 
trayed  as  simple  tick  mark  milestones  chi  the  program  schedule.  There 
are  many  opportunities  throughout  the  life  cycle  of  a  program  where  the 
dangers  of  "tick  mark  syndrome"  can  be  recognized  and  avoided.  This,  in 
turn,  will  help  alleviate  the  problem  of  promising  an  overly  optimistic 
IOC  date.  Again,  I  will  expand  cm  recommended  solutions  to  some  of 
these  problems  in  the  next  section. 

Another  major  area  where  I  can  see  programs  getting  into  cost, 
schedule  and  supportability  difficulties  is  that  of  complex  ancillary 
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programs  that  must  run  concurrently  with  the  primary  hardware  program. 
These  ancillary  programs  are  numerous,  and  each  breeds  its  own  cult  of 
experts  who  place  demands  on  the  program  that  must  be  dealt  with.  Three 
major  programs,  which  I'll  call  the  "monster  programs"  are  the  Test 
Program,  Integrated  Logistic  Support  (ILS),  and  the  Training  Devices 
Program.  (Technically,  training  devices  are  a  subset  of  ILS,  but  they 
can  be  too  costly  and  too  complex  to  hide  under  the  ILS  blanket.) 

The  Ttest  Program- 

As  has  already  been  shown,  testing  is  critical  to  a  program's 
success  or  failure,  because  test  results  are  used  to  guide  a  program 
through  its  major  decision  points.  In  fact,  most  large  project  offices 
will  form  a  test  branch  very  early  in  a  program's  life  cycle.  The 
greatest  challenge  for  a  test  program  planner  is  to  be  able  to  under¬ 
stand  and  define  design  requirements  in  detail  and  to  translate  these 
into  test  plans  that  can  be  implemented  and  agreed  to  by  the  contractor. 
Nothing  will  unnerve  a  contractor  faster  than  to  require  him  to  con¬ 
tractually  commit  himself  to  achieve  design  requirements  that  must  meet 
nebulous  testing  parameters.  Even  the  most  simple  requirements  and 
specifications  can  lead  to  ambiguity.  For  example,  let's  say  a  system 
must  meet  certain  physical  dimensions.  Do  these  dimensions  include 
detachable  items  such  as  antennas?  Does  operating  weight  include  all 
consumable  supplies  and  personal  equipment  of  the  crew?  Under  what 
conditions  must  top  speed  be  achieved?  And  so  forth.  If  a  contractor 
and  the  program  manager  don't  have  a  firm  agreement  on  what  is  to  be 
tested,  and  how  the  results  are  to  be  interpreted,  there  is  no  end  to 
the  possible  schedule  slip6  and  cost  overruns  that  can  occur. 

The  number  of  tests  a  system  is  required  to  go  through  if  it  is 
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following  a  standard  development  plan  is  great.  Each  milestone  is 
coupled  to  a  DT/OT  requirement;  these  tests  may  generate  follow-on  test 
requirements  if  the  hardware  does  not  do  well,  or  design  changes  are 
significant  enough  to  require  separate  testing.  The  OT/OT  cycle 
describes  only  the  formal  TECOM  or  OTEA  involvement  in  testing.  Hidden 
within  the  system  specification  is  an  additional  family  of  tests  asso¬ 
ciated  with  the  "-ilities,"  e.g.,  maintainability,  reliability,  availa¬ 
bility,  environmental  tests  and  so-called  shake- rattle-and-roll  testing. 
All  this  testing  is  meaningless  if  there  isn't  early  agreement  -  spelled 
out  in  the  terms  and  conditions  of  the  contract  and  the  technical  speci¬ 
fications  -  on  how  tests  are  to  be  run  and  how  the  results  are  going  to 
be  used  to  determine  whether  or  not  the  contractor  has  met  his  require¬ 
ments.  Even  though  a  system  may  go  through  severe  testing  and  either 
passes  or  has  design  modifications  made  to  correct  test  failures,  there 
always  seem  to  be  a  number  of  early  failures  when  a  system  is  fielded. 

If  these  failures  are  numerous  and  widespread  a  new  system  can  very 
quickly  acquire  a  bad  reputation  which  it  never  can  live  down.  Why  is 
it  that  a  well  tested  system  can  develop  new  problems  once  it  is 
fielded?  I  attribute  this  primarily  to  the  kid-glove  treatment  a  system 
is  apt  to  receive  during  its  formal  test  program.  A  typical  complex 
system  will  have  its  crews  handpicked  from  FORSOOM  units.  These 
soldiers  will  be  sent  TEY  to  the  contractor's  plant  where  they  will  be 
put  up  in  a  local  motel,  generally  wear  civilian  clothes  and  enjoy  a 
very  intense  level  of  personalized  training.  Their  instructors  are 
highly  qualified  design  engineers  or  technicians  who  know  every  idio¬ 
syncrasy  of  the  equipment  they  are  working  with,  including  all  the 
tricks  used  to  fix  the  equipment  that  aren't  published  in  the  draft 
technical  manuals.  This  highly  select  crew  is  then  used  to  test  the 


equipment  under  government  supervision.  Whether  it  is  a  conscious 
effort  on  the  part  of  the  crew,  or  not,  is  debatable,  but,  whatever  the 
reason,  test  systems  receive  better  treatment  than  the  actual  system 
will  when  it  is  fielded.  Even  though  crews  from  the  units  receiving  the 
equipment  undergo  extensive  new  equipment  training,  it  just  does  not 
meet  the  level  of  sophistication  experienced  by  the  original  factory 
trained  test  crews. 

To  counter  this  problem  of  the  highly  trained  test  crew  being  used 
to  validate  system  performance  it  would  be  tempting  to  do  more  testing 
with  regular  troop  units  operating  the  equipment  under  the  more  realis¬ 
tic  conditions  of  everyday  operations.  The  problem  with  this  approach 
to  testing  is  that  it  becomes  very  difficult  to  perform  failure  analy¬ 
sis,  e.g.,  how  is  the  design  engineer  to  know  if  his  design  was  weak  or 
if  the  equipment  was  abused  by  improper  operation  or  maintenance?  There 
is  no  clear  solution  to  the  test  problem.  What  is  clear  is  that  a 
poorly  defined  test  program  can  lead  to  catastrophic  problems  from 
contract  disputes  to  bad  press  or  congressional  criticism. 

Intearated  Loaistic  Suooort. 


In  the  long  run,  ILS  is  perhaps  the  most  critical  of  all  the 
program  factors  influencing  the  success  or  failure  of  a  program.  A  new 
system  that  is  fielded  without  adequate  support  does  not  meet  its 
requirements,  even  though  its  design  parameters  may  have  been  met.  ILS 
is  the  most  difficult  aspect  of  a  program  to  execute  properly.  Early  in 
this  paper  I  mentioned  the  psychology  of  a  system's  acquisition  life 
cycle:  the  very  last  question  people  ask  of  a  system  is,  "can  we  take 
care  of  it?"  The  literature  associated  with  ILS  has  increased  expo¬ 
nentially  over  the  past  few  years.  ILS  as  a  concept  first  appeared  in 


the  1970's;  its  various  components  are  many  and  complex.  The  most 
recent  guide  (10)  lists  these  elements  of  a  complete  1LS  program: 

-  The  maintenance  plan 

-  Manpower  and  personnel 

-  Supply  support 

-  Support  and  test  equipment 

-  Training  and  training  devices 

-  Technical  data 

-  Computer  resources  support 

-  Packaging,  handling,  storage  and  transportation 

-  Facilities 

The  failure  of  the  program  manager  to  execute  any  one  of  these  elements 
properly  can  completely  stifle  the  initial  fielding  of  new  equipment.  A 
million  dollar  tank  can  very  quickly  be  deadlined  for  the  lack  of  a 
$1,000  piece  of  test  equipment.  Each  one  of  the  ILS  elements  has  its 
own  experts  and  advocates  and  its  own  set  of  agencies  that  must  be 
involved.  The  task  of  adequately  planning  and  coordinating  the  effort 
is  monumental.  What  makes  the  task  nearly  impossible  to  do  perfectly  is 
the  fact  that  ILS  is  not  a  sequential  event  in  the  acquisition  process, 
but  it  pervades  the  entire  life  cycle  of  the  system  from  its  initial 
conceptualization  to  the  end  of  its  useful  service  in  the  inventory  - 
cradle- to-grave,  as  it  is  often  expressed.  Ideally,  a  logistics  engi¬ 
neer  would  like  to  have  the  time  to  derive  his  ILS  elements  from  a 
hardware  design  that  is  firm  and  has  been  successfully  tested.  Figure  7 
shows  this  ideal  process  graphically.  The  ILS  manager,  working  from 
design  drawings  and  prototype  hardware,  would  develop  his  manuals, 
special  tools,  spare  parts  requirements,  etc.,  and  then  test  all  these 
items  in  a  system  that  approaches  the  actual  production  design. 
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THE  IDEAL  ILS  PROCESS 


Problems  in  maintainability  would  then  be  fed  back  into  the  design 
department  so  that  appropriate  adjustments  could  be  made.  This  is  a 
nice  leisurely  process  designed  to  give  the  ILS  manager  time  to  develop 
his  products  from  a  reasonably  firm  data  base,  test  them,  and  influence 
design  changes  before  the  final  design  is  commited  to  production. 
Unfortunately,  there  are  two  major  drawbacks  to  this  ideal  program. 

First  of  all,  there  just  isn't  enough  time  in  a  program  to  allow  this 
sequential  development  of  ILS;  secondly,  by  waiting  for  the  design  to  be 
completed,  the  maintenance  engineer  misses  the  opportunity  to  change  the 
design  early  to  make  it  more  maintainable.  The  problem  of  the  ILS 
manager  is  to  work  in  parallel  with  the  design  engineer  so  that  both 
products  are  completed  at  about  the  same  time  and  can  be  tested 
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together.  In  fact,  this  parallelism  is  the  very  nature  of  textbook  ILS 
-  a  continuous  process  that,  in  theory,  results  in  a  complete  and  sup¬ 
portable  piece  of  equipment  that  meets  all  its  requirements  when  the  IOC 
is  achieved.  In  practical  terms,  an  ILS  program  cannot  be  developed 
simultaneously  with  the  hardware  program.  As  a  system  matures,  more  and 
more  of  the  ILS  documentation  is  developed,  principally  in  the  form  of 
technical  manuals,  tool  lists,  spares  lists,  etc.,  which  require  more 
and  more  time  and  effort  to  change  every  time  a  hardware  change  is  made. 
In  today's  climate  of  the  "comic  book"  tech  manuals  there  are  literally 
tens  of  thousands  of  pages  associated  with  a  complex  system,  such  as  a 
fighting  vehicle.  It  becomes  nearly  impossible  to  manage  change  in  a 
timely  manner;  yet,  if  this  is  not  accomplished,  supportability  becomes 
a  major  issue.  A  poor  ILS  program  can  seriously  degrade  the  overall 
success  of  an  acquisition  program,  and  cause  many  delays  which  translate 
directly  into  increased  funding  requirements,  i.e,  cost  overruns. 

Training  Devices  Program. 

Training  devices  are  listed  as  an  element  of  ILS;  however,  they 
have  become  such  significant  programs  in  terms  of  importance  and  dol¬ 
lars,  that  they  deserve  the  prominence  as  one  of  the  "monster*  programs. 
Training  devices  have  their  own  set  of  regulations,  doctrine,  and  agen¬ 
cies  associated  with  them.  The  timely  development,  production  and 
fielding  of  training  devices  will  enable  TOADOC  or  the  field  commands  to 
conduct  realistic  training  without  having  to  tie  up  millions  of  dollars 
worth  of  actual  operational  hardware.  Delays  in  fielding  training 
devices  can  divert  resources  needed  for  the  end  item  they  are  designed 
to  support,  and  can  cause  delays  in  fielding  of  the  end  items  because  of 
a  lack  of  trained  crews.  The  manager  of  the  training  devices  program 


must  develop  his  system  in  parallel  with  the  primary  hardware,  but,  as 
in  the  development  of  other  ILS  items,  must  wait  for  the  hardware  design 
to  evolve  before  he  can  analyze  training  tasks,  levels  of  performance, 
density  of  training  equipment  and  so  forth.  The  training  device 
development,  as  a  very  important  part  of  the  acquisition  process,  can 
very  easily  contribute  to  overall  system  problems  if  it  is  not  carefully 
managed  throughout  the  various  phases  of  the  system  life  cycle. 
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INFLUENCING  TOE  ACQUISITION  PROCESS 


We  have  seen,  in  the  foregoing  section,  many  opportunities  for  the 
acquisition  process  to  run  aground,  suffer  delays  and  overrun  costs. 
There  are  so  many  examples  of  programs  that  have  various  combinations  of 
these  problems  that  it  is  very  easy  to  be  critical  of  the  materiel 
acquisition  process  in  general.  Invariably,  a  program  that  has  prob¬ 
lems,  will  incur  delays;  delays  cost  money;  increased  costs  are  met  with 
resistance  and  often  result  in  decreased  production  quantities; 
decreased  production  quantities  drive  cost  per  unit  up  The  final 
result  is  the  fielding  of  a  system  that  is  long  in  coining  and  terribly 
expensive.  How  can  these  problems  be  avoided?  What  can  be  done  to 
overcome  these  problems?  Is  the  acquisition  process  itself  at  blame,  or 
is  it  just  a  convenient  scapegoat?  I  don't  know  if  I  can  answer  these 
questions  in  an  absolute  manner,  but  I  will  attempt  to  offer  some 
insight  into  possible  strategies  and  solutions  that  will  minimize  some 
of  the  potential  problems  a  system  can  experience. 

The  first  generalized  problem  I  discussed,  the  psychology  of  the 
"Big  Four"  questions,  is  probably  the  most  difficult  to  overcome.  It 
takes  a  farsighted  management  team  to  look  8-12  years  ahead  and  plan  for 
all  the  challenges  that  will  arise.  Yet,  for  a  program  to  be  suc¬ 
cessful,  all  the  challenges  must  be  met  early  in  the  program.  Realistic 
cost  estimates  and  scheduling  and  early  funding  of  a  program  are  keys  to 
success.  In  fact,  throughout  this  section,  I  will  tend  to  foroe  my  view 
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that  adequate  and  timely  funding,  coupled  with  sound  planning,  is  the 
fuel  of  program  success.  The  acquisition  process,  though  difficult  and 
complex,  is  nothing  more  than  a  common  sense  sequence  of  events  designed 
to  cover  all  elements  of  a  program.  Much  can  be  done  to  remove  or 
decrease  irritants  to  a  program;  this  is  exactly  how  I  view  the  Carlucci 
initiatives:  they  are  designed  to  decrease  external  requirements  on  the 
program  manager  -  and  also  give  him  more  authority  -  so  that  he  can 
devote  more  time  and  energy  to  actual  internal  management  problems  than 
to  external  pressures. 

Probably  the  most  important  aspect  of  program  stability  early  in  a 
program  development  is  to  insist  on  a  firm  requirement.  If  the  user,  or 
army  hierarchy,  or  Congress  tinkers  with  or  modifies  a  requirement,  an 
immediate  cost  and  schedule  impact  must  be  made  known  to  the  decision 
authority  involved  in  changing  the  requirement.  There  is  nothing  wrong 
with  modifying  a  requirement  for  legitimate  reasons,  but  it  is 
absolutely  critical  that  changes  be  controlled  and  recognized  for  the 
turbulence  they  can  cause.  The  Bradley  Fighting  Vehicle  is  a  good 
example  of  a  system  that  has  undergone  significant  requirement  changes 
throughout  its  development  cycle.  Because  the  current  configuration  is 
quite  a  bit  different  than  earlier  concepts,  costs  have  increased  consi¬ 
derably  over  early  estimates;  however,  it  is  very  unfair  to  compare 
today's  costs  with  yesterday's  original  requirement  and  attribute  the 
difference  as  a  cost  overrun  and  a  case  of  mismanagement.  When  trade¬ 
offs  and  compromises  are  made  they  must  be  thoroughly  documented  and 
made  known  to  every  management  level. 

The  "tick  mark"  syndrome  is  a  little  easier  to  overcome  than  some 
of  the  more  difficult  problems  discussed  above.  Almost  every  major 
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program  milestone  revolves  around  a  procurement  action  of  some  sort, 
i.e.,  a  contract  award,  a  contract  modification,  or  the  issue  of  a 
Request  for  Proposed,  etc.  The  Defense  Acquisition  Regulation  (DAR)  is 
so  complicated  that  even  the  most  simple  requirement  can  require  hun¬ 
dreds  of  pages  of  contract  documents.  Good  planning  can  alleviate  some 
of  the  lead  time  problems,  but  it  must  be  remembered  that  both  the 
contracting  officer  and  the  contractor  need  adequate  time  to  respond  to 
requirements.  One  good  technique  to  reduce  procurement  lead  times  is  to 
execute  the  original  contract  package  with  severed  contract  options  so 
that  when  it  comes  time  to  move  from  one  program  phase  to  another  a 
contract  option  is  exercised,  a  simple  contract  modification  is  nego¬ 
tiated  and  the  contractor  can  proceed  without  a  loss  of  continuity  in 
his  work  load.  It  must  be  remembered  that  major  program  transition 
points,  e.g„  source  selection,  or  initial  production,  take  a  massive 
procurement  effort.  Program  schedules  should  recognize  this  early  in 
the  program  life  cycle  so  that  testing  dates  and  IOC's  don't  crowd 
procurement  actions  with  unrealistic  starting  points. 

The  converse  to  this  problem  of  trying  to  condense  a  program  too 
much  is  allowing  a  program  to  have  gaps  in  it  so  that  the  contractor  is 
unable  to  stabilize  his  work  force.  Again,  sound  planning  is  the  key  to 
avoiding  this  problem,  and  some  foresight  in  procurement  strategy  and 
contract  writing  will  allow  the  contractor  to  be  funded  during  major 
program  transition  points.  If  this  isn't  done,  and  the  contractor  is 
forced  to  transfer  or  ley  off  some  of  his  personnel,  more  start  up  time 
will  be  required  by  the  contractor  at  the  beginning  of  a  new  phase. 
There  is  much  effort  than  can  continue  on  during  these  program  lulls, 
particularly  in  testing  and  ILS  programs.  The  program  manager  should 
look  to  these  ancillary  programs  as  a  means  to  keep  a  reasonable  work 
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load  on  the  contractor. 

Once  a  production  point  is  reached,  multi-year  funding  is  a  power¬ 
ful  tool  to  keep  the  contractor  flowing  smoothly.  An  early  commitment 
on  the  part  of  the  government  allows  the  prime  contractor  to  make  early 
commitments  with  his  vendors  and  sub-contractors,  thus  resulting  in  a 
more  economical  business  arrangement.  Multi-year  contracts  must  allow 
both  the  contractor  and  the  government  some  flexibility.  If  problems 
should  arise  and  hardware  modifications  are  needed,  there  must  be  some 
way  to  contractually  protect  the  interests  of  both  parties. 

Sometimes  the  "tick  mark  syndrome"  is  directly  related  to  an 
urgen  program  action.  Such  is  the  case  of  the  Required  Operational 
Capability  (ROC)  document.  It  is  very  tempting  to  indicate  a  ROC  as  a 
single  point  on  a  program  schedule.  A  careful  look  at  the  Material 
Acquisition  Guide  (11)  will  show  that  the  ROC  process  takes  about  six 
months.  Figure  8  shows  this  in  detail.  It  can  be  seen  that 
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THE  ROC  PROCESS 
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time  is  spent  in  coordinating  the  draft  between  two  major  commands, 
TRADOC  and  DAROOM.  The  9th  Infantry  Division  has  discovered  that  this 
process  can  be  shortened  dramatically  by  causing  the  appropriate  person¬ 
nel  to  sit  down  together  and  hammer  out  the  basic  requirement,  agree  on 
it,  and  get  it  back  into  DAROOM  channels  so  that  the  appropriate  action 
can  be  taken  on  it.  The  9th  Division  has  used  the  term  "mini -ROC"  to 
describe  this  process.  This  technique  will  shorten  a  six  month  process 
into  a  few  weeks.  There  are  similar  opportunities  throughout  the  acqui¬ 
sition  process  where  long  delays  can  be  avoided  by  condensing  the  amount 
of  time  it  takes  to  process  major  program  documents.  The  ultimate  key 
to  successfully  shortening  the  generation  of  these  documents  is  to  have 
the  Department  of  Army  Staff  fully  attuned  to  what  is  going  cm  so  that, 
when  DA  approval  is  required,  it  comes  quickly  and  without  problems. 

Dealing  with  the  three  "monster  programs"  in  such  a  way  that  the 
overall  program  schedule  is  not  slipped  is  much  more  difficult.  These 
programs  must  be  concurrent  with  the  hardware  program  in  order  to 
shorten  the  overall  acquisition  time;  however,  so  much  of  the  testing 
and  ILS  is  dependent  on  early  identification  and  control  of  the  hardware 
configuration,  it  becomes  very  costly  to  keep  up  with  engineering 
changes.  This  effort  must  be  accomplished  if  schedule  delays  are  to  be 
avoided.  The  only  way  to  do  this  is  to  adequately  fund  these  "monster 
programs"  early  in  the  program  life  cycle  so  that  schedule  and  cost 
turbulence  are  minimized.  Training  device  problems  can  be  avoided  if 
early  planing  is  made  for  the  use  of  operational  hardware  to  support  the 
training  of  initial  crews.  A  slow,  phased  fielding  program  will  also 
reduce  the  impact  of  unforeseen  problems.  The  most  important  thing  to 
keep  these  problems  from  blossoming  into  massive  cost  overruns  is  to 
realisitcally  plan  schedules,  and  fund  early.  It  is  much  better  to 
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fight  funding  problems  early  in  the  program  than  to  underfund  program 
elements  oily  to  have  them  appear  later  as  overruns  amidst  the  charges 
of  "mismanagement." 
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CONCLUSIONS 

As  a  result  of  this  look  at  the  acquisition  process,  I  arrive  at 
the  conclusion  that  there  is  nothing  basically  wrong  with  the  framework 
of  the  materiel  acquisition  process.  It  is,  perhaps,  complex  and  overly 
regulatory  in  some  respects,  but  its  primary  function,  that  of  mapping 
out  an  acquisition  strategy,  is  basically  sound.  Hie  problem  is  to  know 
how  to  operate  successfully  within  this  environment.  Personnel  turbu¬ 
lence  leads  to  many  problems  because  key  decisionmakers  who  initiate 
programs  are  normally  long  gone  by  the  time  a  new  system  is  ready  for 
fielding.  A  carefully  documented  program  that  enjoys  hardware  successes 
can  normally  survive  the  many  problems  it  will  encounter  along  the  way. 
A  sound  government-industry  relationship,  detailed  planning,  and  early 
funding  appear  to  be  the  main  ingredients  for  keeping  a  program  on 
track.  Essential  tasks  that  are  put  off  early  in  a  program  will  always 
come  back  to  haunt  the  program  later. 

Finally,  a  program  or  project  manager  who  has  the  respect  and 
confidence  of  his  contractor  and  the  backing  of  his  superiors,  can 
overcome  nearly  every  obstacle  by  shear  dint  of  effort  and  extraordinary 
energy.  The  constant  selling  of  the  program,  the  formulation  of  a 
government  management  team,  lots  of  money,  and  a  little  luck  will  allow 
a  system  to  wander  through  the  acquisition  labyrinth  with  minimum  delays 
and  moderate  or  no  cost  overruns. 
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